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ABSTRACT 


Conventional  debugger  systems  rely  on  user  guidance  to 
conduct  error  localization  procedures.  System  procedures 
are  typically  time  consuming  and  inefficient  due  in  part  to 
the  human  factor.  In  addition,  compatibility  is  limited 
among  different  hardware  and  software  systems.  These  fac¬ 
tors  inhibit  program  design  and  development  while  increasing 
system  cost. 

A  prototype  software  system  has  been  developed  that  au¬ 
tomates  the  debugging  process.  The  system  uses  automation 
as  an  alternative  technique  for  improving  current  debugger 
designs.  Problem  areas  associated  with  typical  debugger 
systems  are  presented.  Concepts  employing  automation  are 
supplied  to  remedy  these  deficiencies.  Validation  of  these 
concepts  are  demonstrated  by  the  prototype  system.  The  pro¬ 
totype  system  exploits  automation  concepts  through  test  case 
verification  and  provides  the  framework  for  an  automated  de¬ 
bugger  system. 


TABLE  OF  CONTENTS 


Page 


List  of  Figures  vi 

Chapter 

I.  INTRODUCTION  .  1 

A.  Program  Error  Localization  .  1 

B.  The  Research  Problem  .  2 

II.  BACKGROUND  .  4 

A.  Control  Flow  Analysis  .  4 

B.  Data  Flow  Analysis  .  7 

C.  Summary  of  Flow  Analysis  .  10 

D.  Dependence  Graph  Construction  .  11 

III.  ERROR  LOCALIZATION  .  15 

A.  System  Design  Issues  .  15 

B.  Enhanced  Methods  for  Traditional  Designs  22 

C.  Summary  .  25 

IV.  SYSTEM  DEVELOPMENT  AND  RESULTS  .  27 

A.  Prototype  System  Development  .  27 

B.  initialization  Phase  .  30 

C.  Error  Localization  Processing  Phase  ....  35 

D.  Termination  Phase  .  42 

E.  Prototype  System  Verification  .  44 

V.  CONCLUSIONS  AND  RECOMMENDATIONS  .  48 

A.  Conclusions  .  48 

B.  Recommendations  .  50 


Appendix  A.  TEST  CASES  .  51 

Appendix  B.  PROTOTYPE  SYSTEM  SOURCE  CODE  .  54 


Bibliography 


LIST  OF  FIGURES 


Figure  1 
Figure  2 
Figure  3 
Figure  4 
Figure  5 
Figure  6 
Figure  7 
Figure  8 


Control  Flow  Analysis  . 

Data  Flow  Analysis  . 

Dependence  Graph  Representation  . . . 

Program  Design  Cycle  . 

Error  Localization  Cycle  . 

Initialization  Phase  . . 

Error  Localization  Processing  Phase 
Termination  Phase  . 


Chapter  I 


INTRODUCTION 


Recent  software  system  designs  have  demonstrated  the 
need  for  superior  development  techniques.  With  computer 
software  expenses  constituting  about  90%  of  total  system 
cost  [10],  alternative  methods  are  needed  to  provide  more 
efficient  approaches  to  software  development.  One  such 
method  is  automation.  Fully  automated  support  of  software 
development  can  result  in  a  20-25%  reduction  in  cost  [10]. 

A.  Program  Error  Localization 

Program  debugging  is  the  most  tedious  task  associated 
with  software  development.  Conventional  systems  require 
user  interaction  at  all  levels  due  to  the  lack  of  automation 
in  the  error  localization  process.  A  source  code  program  is 
typically  prepared  before  execution  in  an  attempt  to  pro¬ 
vide  the  user  with  information  necessary  for  localizing  er¬ 
rors.  It  is  the  user's  responsibility  to  apply  this  infor¬ 
mation  correctly.  In  addition,  the  user  is  responsible  for 
program  maintenance,  conducting  debugger  operations,  and 
a  host  of  other  menial  tasks.  These  menial  tasks  are  tedi¬ 
ous  and  may  introduce  additional  errors  not 
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with  the  debugging  problem.  These  errors  are  normally 
caused  by  user  fatigue  and  can  go  undetected  throughout  the 
debugging  process.  Incorrect  application  of  the  information 
provided  can  result  in  time  spent  in  areas  where  problems 
I  are  non-existent.  These  errors  can  result  in  a  tremendous 

•  amount  of  wasted  time  and  increased  cost. 

i 

i 

|  B.  The  Research  Problem 

I 

* 

^  Automation  is  a  method  of  improving  current  debugger 

)  designs.  Automating  tasks  can  reduce  the  number  of  acciden- 

; 

tal  errors  introduced  into  a  debugging  session  and  reduce 
user  frustration.  In  addition,  automation  reduces  cost  and 

» 

time  factors  while  increasing  system  performance. 

■ 

This  research  focuses  on  providing  an  automated  de¬ 
bugger  system.  A  prototype  system  will  be  developed  to 
prove  concepts  associated  with  this  research.  Menial  tasks 
associated  with  typical  debug  sessions  will  be  automated. 
Of  fundamental  importance  will  be  the  control  of  debugger 
operations  by  the  prototype  system.  Using  a  data  base  con- 
structed  before  program  execution,  the  prototype  automati- 
cally  isolates  program  errors.  This  feature  will  reduce 
user  interaction  to  a  minimum.  The  prototype  system  will  be 
exercised  using  test  programs  to  provide  a  visual  inspection 
of  debugger  capabilities. 

The  objective  of  this  research  is  two-fold:  to  provide 


I 


^  ■ 

■/I 

■  Jj 


I 


?a 


3 


,S 
*  * 


3 


< 

« 

a  'smart'  debugger  through  automation  and  to  minimize  the 
need  for  user  intervention.  Both  factors  support  the  idea 
of  a  universal  debugger  concept.  The  following  research 
satisfies  these  objectives  by  demonstrating  a  possible  pro¬ 
totype  system. 

Chapter  II  discusses  source  code  preparation  necessary 
to  provide  the  facilities  for  an  automated  debugger  system. 
Problems  with  conventional  debugger  systems  and  techniques 
for  improving  these  problems  through  automation  are  present¬ 
ed  in  Chapter  III.  The  prototype  system  that  demonstrates 
these  concepts  is  described  in  Chapter  IV.  Chapter  V  pro¬ 
vides  concluding  remarks  and  suggested  areas  for  further 
research. 
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Chapter  II 


BACKGROUND 


The  effectiveness  of  an  automated  system  commences  with 
program  data  base  design.  An  algorithm  scans  the  source 
code  acquiring  pertinent  details  and  places  them  in  a  pro¬ 
gram  data  base  for  future  use.  Additional  algorithms  ex¬ 
tract  information  from  this  program  data  base  to  make  deci¬ 
sions  regarding  automated  system  guidance.  increasing  au¬ 
tomated  system  capabilities  requires  a  more  complex  algo¬ 
rithm  and  data  base  design. 

Program  data  base  design  begins  with  a  flow  analysis  of 
the  source  code  program.  Flow  analysis  consists  of  two  dis¬ 
tinct  parts:  control  flow  analysis  and  data  flow  analysis. 
The  resultant  structure  of  flow  analysis  is  a  dependence 
graph  forming  a  program  data  base  to  be  manipulated  by  the 
automated  system. 

A.  Control  Flow  Analysis 

Control  Flow  Analysis  ( CFA )  depicts  the  potential,  pos¬ 
sible  flow  of  control  from  one  statement  to  another  in  a 
program.  This  flow  of  control  is  typically  represented  by  a 
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directed  graph  termed  the  'control  flow  graph'  or  simply 
'flow  graph'.  A  flow  graph  must  have  the  following  two  pro¬ 
perties: 

(1)  A  single  entry  node  at  which  to  begin,  but  may 
have  more  than  one  exit  node. 

(2)  A  path  must  exist  from  the  entry  node  to  every 
node  in  the  flow  graph. 

Formally  a  flow  graph  is  represented  by  the  triple 
G  -  (N,  E,  SO),  where  (N,  E)  is  a  directed  graph  and  N  and  E 
are  node  and  edge  sets  respectively.  The  entry  node  SO  is 
an  element  of  N  to  which  there  is  a  path  to  every  node  of 
the  flow  graph.  In  general,  the  nodes  of  a  flow  graph, 

N  -  { SO , SI , S2 , . . . , Sn} ,  represent  program  statements  and  a 
set  of  edges,  E,  represent  control  paths  from  one  statement 
to  another  [4J.  The  successors  of  node  Sm  are  nodes  Sn  for 
which  there  exists  a  path  (Sm,...,Sn).  The  predecessors  of 
node  Sn  are  all  nodes  Sm  for  which  there  exists  a  path  from 
Sm  to  Sn  [1].  Figure  1  depicts  a  pictorial  representation 
of  a  typical  control  flow  graph  and  corresponding  informa¬ 
tion  using  test  case  two  found  in  Appendix  A. 2. 

The  purpose  of  CFA  is  to  encode  the  flow  of  control  of 
a  program  for  use  in  the  data  flow  analysis  that  follows 
[6].  The  flow  graph  provides  the  data  flow  analysis  pro¬ 
cedures  with  an  appropriate  structure.  This  structure 
guides  the  analysis  from  one  program  unit  to  another  in  a 
specified  order  [4).  Several  methods  exist  for  flow  of  con¬ 
trol  transformations  applied  to  the  control  flow  structure 
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during  CFA  to  simplify  the  ensuing  data  flow  analysis.  Node 
splitting  and  graph  transformation  are  two  such  techniques 
available  [  6  J -  No  more  time  than  necessary  will  be  spent  in 
CFA  except  to  provide  a  useful  flow  graph  for  data  flow 
analysis . 
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B.  Data  Flow  Analysis 

Data  Flow  Analysis  { DFA )  is  the  pre-execution  process 
of  ascertaining  and  collecting  information  about  the  use  of 
quantities  in  a  computer  program.  Variables  are  normally 
selected  as  the  quantities  under  observation,  because  they 
provide  fundamental  information  from  which  other  information 
can  be  determined  [61.  In  DFA,  the  flow  graph,  produced  in 
CFA,  is  scanned  systematically  to  obtain  information  about 
the  use  of  variables.  Certain  inferences  can  be  made  about 
the  use  of  these  variables  at  other  points  of  the  program. 
A  DFA  must  in  effect  examine  all  possible  execution  se¬ 
quences  starting  at  the  entry  node  to  see  if  the  variable 
under  consideration  is  ever  used  again  in  successor  nodes 
(statements).  Algorithms  exist  to  accomplish  this  task  [4] 
and  the  prototype  system  will  not  consider  these  any  furth¬ 
er.  Information  discovered  during  data  flow  analysis  is 
placed  into  a  suitable  structure  for  future  use. 
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locating  anomalies  in  the 
teps  as  stated  by  Fosdick  and 
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(1)  Determine  whether  an  anomaly  exist. 

(2)  Find  a  path  containing  the  specific  anomaly. 

(3)  Attempt  to  determine  whether  the  path  is 
executable . 

Step  3  above  can  be  done  through  techniques  such  as  symbolic 
execution;  however,  such  techniques  are  costly  and  should  be 
avoided  if  possible  [4]. 

In  these  terms,  DFA  seems  to  be  better  suited  for  tasks 
such  as  code  optimization  or  syntax  analysis  for  compiling 
source  code.  By  extending  these  three  steps,  a  systematic 
approach  can  be  established  for  a  prototype  debugger  system. 
The  function  of  this  system  is  to  automate  tasks  normally 
performed  manually  by  the  user.  The  prototype  system  envi¬ 
sions  three  corresponding  steps  for  error  localization: 

(1)  Determine  whether  an  anomaly  exists  by 
querying  the  user  after  program  execution 
followed  by  additional  executions  if 
necessary . 

(2)  Find  a  path  containing  the  anomaly. 

(3)  Localize  the  error  by  suggesting  the  node 

or  statement  that  could  be  the  possible  or  suspect 
source  of  the  anomaly. 

Extending  the  normal  definitions  associated  with  DFA,  addi¬ 
tional  information  can  be  acquired  to  support  complex  de¬ 
bugger  facilities.  These  3  steps  continue  to  require  a  typ¬ 
ical  DFA  before  program  execution  and  infer  usage  of  this 
information  during  program  execution.  Figure  2  demonstrates 
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DFA  using  source  code  of  test  case  two  located  in  Appendix 
A. 2.  This  DFA  was  performed  using  definitions  proposed  by 
Korel  [7].  These  definitions  can  extend  typical  data  flow 
analysis  to  support  the  debugger  facilities  suggested. 
These  definitions  will  be  discussed  further  in  section  D. 

C.  Summary  of  Flow  Analysis 

In  summary,  DFA  provides  a  search  over  the  nodes  of  a 
flow  graph  created  by  CFA  to  determine  certain  relationships 
between  the  uses  of  data  in  various  statements.  Thus,  be¬ 
fore  DFA  can  begin,  a  correspondence  between  statements  of  a 
program  and  the  nodes  of  a  flow  graph,  or  CFA,  must  be  esta¬ 
blished.  DFA  will  want  to  associate  nodes  in  a  flow  graph 
with  sets  of  variables  that  have  been  either  referenced  or 
defined.  Once  this  association  has  been  made,  flow  analysis 
will  be  complete. 

Specifically,  the  prototype  system  is  not  concerned 
with  typical  methods  [1,4,6]  used  to  detect  anomalies  but 
with  detection  of  underlying  errors  requiring  interactive 
input  from  the  programmer.  CFA  and  DFA  occur  before  program 
execution.  The  prototype  system  assumes  a  suitable  CFA  and 
DFA  has  been  performed  on  the  program  before  execution  and 
that  the  program  source  is  ready  for  analysis. 
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D.  Dependence  Graph  Construction 

The  end  product  of  flow  analysis  results  in  the  estab¬ 
lishment  of  a  structure  with  information  about  the  relation¬ 
ship  of  program  statements  and  variables.  Many  such  struc¬ 
tures  exist,  but  of  particular  interest  is  the  dependence 
graph  incorporated  by  Korel  [7].  The  dependence  graph 
resolves  the  relationship  between  program  statements  and 
variables  through  three  types  of  dependences  or  influences. 
As  defined  by  Korel  [7],  these  entail: 

(1)  Data. 

(2)  Control. 

(3)  Control-data. 

Data  dependence  occurs  when  one  statement  assigns  a 
value  to  a  variable  of  data  and  another  statement  uses  the 
value  of  the  data  variable.  The  data  variable  must  not  be 
redefined  between  the  points  of  assignment  and  use  or  the 
use  will  become  dependent  on  the  new  definition  of  the  data 
variable . 

Control  dependence  is  defined  between  a  statement  con¬ 
taining  a  test  condition,  and  the  succeeding  statements  that 
may  be  chosen  to  execute  based  on  results  of  the  test  condi¬ 
tion  . 

Control-data  dependence  is  a  combination  of  data  and 
control  dependences.  Control-data  dependence  is  the  result 
of  a  data  variable  changing  because  a  different  control  path 
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was  chosen.  A  control  path  is  selected  from  the  results  of 
a  test  condition.  A  data  variable  is  changed  within  the 
control  path.  On  leaving  this  control  path,  the  data  vari¬ 
able  is  referenced.  The  value  of  the  data  variable  is 
dependent  on  modifications  made  to  it  while  inside  the  con¬ 
trol  path.  The  control  path  affected  the  value  of  the  data 
variable  resulting  in  a  new  data  dependence,  thus  control- 
data  dependence  [7]. 

The  result  of  CFA  and  DFA  is  a  data  base  structure 
(dependence  graph)  containing  pertinent  details  of  the 
source  code  program.  DFA  incorporates  dependence  defini¬ 
tions  described  by  Korel  [7)  and  scans  the  CFA  structure 
resulting  in  a  dependence  graph  of  the  source  code  program. 
This  dependence  graph  forms  the  basis  from  which  all  opera¬ 
tions  of  the  prototype  system  revolve.  Using  the  CFA  of 
Figure  1  and  the  above  definitions  to  provide  the  DFA  of 
Figure  2,  an  appropriate  dependence  graph  of  the  source  code 
program  is  shown  in  Figure  3. 

The  dependence  graph  of  Figure  3  is  shown  as  an  adja¬ 
cency  list.  Each  node  contains  information  identifying  the 
relationship  between  program  variables  and  statements.  This 
information  assists  the  prototype  system  in  making  decisions 
about  debugger  operations.  The  prototype  system  obtains 
this  information  by  backtracking  through  the  adjacency  list. 
The  data  base  can  be  represented  with  other  structures  and 
optional  traversal  techniques  exist.  These  methods  were 


I 


nl  — >  null 


n2  — >  null 
n3  — >  null 
n4  — >  n3(c)  — >  null 

n5  — >  n4(c)  — >  nl ( d : num_of_char s )  — >  null 

n6  — >  n4(c)  — >  n2 ( d : num_of_lines )  — >  null 

nl  — >  n5(  cd:nunt_of_chars  )  — > 

nl { d : num_cf_chars )  — >  null 

n8  — >  n6(cd:num_of  lines)  — > 

n2 ( d : num_of_Tines )  — >  null 

n#  «  source  code  statement  or  node 
d  —  data  dependence 
c  —  control  dependence 
cd  -■»  control-data  dependence 

Figure  3:  Dependence  Graph  Representation 
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chosen  merely  to  demonstrate  the  data  base  design  and  the 
prototype  system.  However,  these  methods  seem  to  be  natural 
choices  for  the  proposed  system. 
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Chapter  III 


ERROR  LOCALIZATION 


Traditional  debugger  systems  typically  possess  numerous 
attributes  making  them  complex  and  difficult.  These  attri¬ 
butes  impose  additional  hardships  on  the  operator.  Current 
trends  are  toward  a  more  automated  debugging  environment. 
Emphasis  is  placed  on  relieving  operator  responsibility  and 
automating  many  menial  processes.  In  addition,  current 
technology  provides  resources  to  enhance  these  systems 
beyond  traditional  approaches. 

A.  System  Design  Issues 

A  representative  program  design  cycle  is  shown  in  Fig¬ 
ure  4.  The  following  list  comprises  issues  associated  with 
conventional  debugger  systems.  These  entail: 

(1)  System  operational  concept  and  interface  language. 

(2)  Information  management. 

(3)  Information  structural  arrangement. 

(4)  Adaptability. 

(5)  Machine  independence  and  flexibility. 

(6)  Error  isolation  techniques. 

(7)  Data  examination. 
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Users  must  be  familiar  with  the  following  breakpoint 
debugging  concepts:  a  working  knowledge  of  system  operation 
and  the  interface  language,  identification  of  the  problem 


area,  and  breakpoint  placement. 

Interface  languages  are  typically  complex  and  cryptic 
in  nature  with  a  minimum  amount  of  suitable  documentation 
available.  A  thorough  knowledge  of  the  debugger  command 
language  is  required  to  efficiently  determine  information 
necessary  for  error  isolation.  Typically,  errors  must  be 
corrected  on  localization  within  the  system  debuggers  host 
operating  system.  Therefore,  several  editors  may  be  used 
before  completing  the  final  product.  Knowledge  of  editors 
and  operating  systems  are  highly  desired.  Examining  the  in¬ 
correct  area  could  result  in  tremendous  amounts  of  wasted 
time  [7].  Placement  of  breakpoints  are  critical  to  effi¬ 
ciently  guide  a  search  for  error  isolation. 

System  or  user  queries  require  a  language  interface. 
Parsing  an  input  response  is  a  tedious  task  dependent  on  the 
complexity  of  the  response  admitted.  Languages  parsed  are 
described  by  a  grammar.  The  grammar  is  a  set  of  definitions 
consisting  of  tokens.  These  definitions  determine  legal 
combinations  of  tokens.  A  method  of  describing  the  syntax 
description  associated  with  language  development  is  the 
Backus-Naur  form  ( BNF ) .  BNF  is  a  shorthand  for  describing 
language  syntax  providing  a  straightforward  method  for 
parser  design  [13].  The  complexity  of  the  BNF  description 


or  language  definition  is  determined  by  the  amount  and  so¬ 
phistication  of  responses  permitted.  The  amount  of  storage 
allocated  for  prompts  and  responses  is  determined  by 
language  complexity.  A  linked-list  organization  is  suitable 
for  preserving  prompts  and  responses. 

Directly  related  to  operational  concepts  and  interface 
languages  are  problems  of  information  management.  Vast 
amounts  of  data  resulting  from  these  problems  about  program 
execution  and  debugger  status  are  maintained  by  the  opera¬ 
tor.  This  is  especially  difficult  for  source  code  of  ample 
size.  The  operator  must  always  be  aware  of  program  execu¬ 
tion  and  system  status  in  current  debugging  environments. 
Normally,  program  listings  in  the  form  of  memory  maps  and 
list  files  are  kept  close  for  examination  during  typical  er¬ 
ror  localization  sessions.  These  must  be  kept  current  to 
preserve  proper  symbol  addresses  and  statement  locations 
within  the  program  segment.  Minor  changes  to  the  program 
during  a  debug  session  can  easily  become  a  tiresome  task  if 
program  listings  and  memory  maps  are  not  kept  current.  Ter¬ 
minating  the  debugger  is  usually  required  to  modify  the 
suspect  program  and  maintain  a  current  set  of  program  list¬ 
ings  and  memory  maps. 

Responding  to  system  or  user  queries  requires  an  infor¬ 
mation  data  base.  Depending  on  system  capabilities,  this 
data  base  can  become  extensive.  Typical  systems  allow  sym¬ 
bolic  debugging  capabilities.  Users  need  not  reference 


program  variables  using  memory  addresses.  This  requires 
construction  and  maintenance  of  symbol  tables  or  similar 
constructs.  The  compiler  commonly  places  symbolic  informa¬ 
tion  into  the  object  modules  it  generates.  The  linker  is 
designed  to  recognize  this  information  and  carries  it 
throughout  the  run-time  phase.  This  permits  referencing 
program  information  during  the  debug  session. 

Increasing  system  capabilities  requires  more  complex 
structures.  ACES  provides  a  convenient  means  to  retrieve 
program  information.  The  concept  requires  a  data  base 
comprised  of  four  tables,  each  table  performing  a  specific 
function  [11].  Korel  describes  a  system  requiring  a  depen¬ 
dence  graph.  This  structure  defines  the  relationship 
between  program  instructions  by  categorizing  them  into 
specific  groups  [7].  Additional  systems  such  as  FACES  [10], 
FAST  [2],  and  DAVE  [9]  require  similar  constructs. 

These  systems  normally  require  complex  links  and 
pointers  for  maintenance.  Additional  mechanisms  such  as 
backtracking  are  required  for  information  extraction. 
Dependent  on  the  number  and  complexity  of  structures,  this 
technique  might  be  inadequate,  requiring  more  complex 
traversal  techniques. 

A  principal  difficulty  of  debugger  systems  is  adapta¬ 
bility.  Conventional  systems  are  designed  for  specific 
hardware  and  languages  and  are  restrictive  in  the  sense  that 
a  separate  debugger  is  required  for  each  language.  These 
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restrictions  inhibit  programmers  by  limiting  language  selec¬ 
tion  associated  with  debugger  support.  Many  designs  are 
inefficient  because  of  this  limitation. 

Limiting  debugger  capabilities  are  machine  independence 
and  flexibility  [10].  Designing  debuggers  for  specific  sys¬ 
tems  stifles  portability  among  machines.  Consideration  to 
the  host  debugger  language  and  choice  of  operating  system 
are  of  utmost  importance.  Selection  of  those  promoting  por¬ 
tability  and  machine-independence  are  desirable.  Languages 
and  operating  systems  currently  exist  supporting  portability 
[5,12].  Typical  systems  restrict  the  operational  environ¬ 
ment  . 

Location  and  correction  of  program  errors  is  a  time 
consuming  and  complex  process.  Several  techniques  exist  to 
do  this  function.  Programs  may  initially  contain  an  enor¬ 
mous  amount  of  problem  areas  that  require  use  of  the 
editing-compiling-linking  (ECL)  cycle  to  be  extremely  ac¬ 
tive.  To  alleviate  this  cycle,  programmers  attempt  program 
patching  of  the  questionable  source.  This  permits  continua¬ 
tion  of  the  debugging  cycle.  The  difficulty  with  patching 
is  the  level  at  which  the  patch  must  be  made,  using  hex  code 
or  mnemonics.  Even  the  most  experienced  programmer  can  have 
difficulty  grasping  this  concept.  Patches  are  difficult  for 
a  variety  of  reasons;  high-level  language  compiler  conven¬ 
tions,  size  of  patch,  and  patch  incorporation  may  generate 
entirely  different  code  [15]. 
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The  most  common  method  is  breakpoint  placement  at  the 
suspect  problem  area.  Once  the  system  breakpoint  is  execut¬ 
ed,  variables  or  test  condition  outcomes  can  be  modified. 
However,  difficulty  arises  in  keeping  track  of  several 
modifications.  Programmers  resort  to  extensive  ECL  cycles 
to  update  and  keep  programs  current  [15].  Once  a  breakpoint 


is  executed,  trace  buffers  are  provided  to  record  past  in¬ 
structions  before  breakpoint  termination.  This  gives  an  ac¬ 
curate  account  of  the  path  executed  up  to  this  point  in 
time.  Many  times  these  provide  little  or  no  information. 
For  example,  if  an  infinite  loop  is  encountered,  the  trace 
buffer  will  contain  isolated  addresses  with  no  information 
of  past  instructions  executed.  The  actual  area  of  in¬ 
correctness  is  lost.  On  reaching  these  breakpoint  areas, 
debugging  procedures  must  be  available  to  the  programmer  for 
immediate  action.  Typical  systems  provide  menu  driven 
prompts  to  guide  the  user.  These  procedures  are  complex  and 
operator  familiarity  is  a  required  prerequisite. 


Although  most  applications  are  developed  in  high-level 
languages,  many  debuggers  reduce  high-level  language  pro¬ 
grams  to  assembly-language  equivalents.  Once  a  breakpoint 
is  reached,  the  programmer  is  normally  forced  to  translate 
between  high-level  source  terms  and  low-level  processor 
specific  terms  [8],  This  increases  frustration  and  injects 
confusion  into  the  debugging  environment.  Access  to  program 
variables  is  difficult.  Typical  debuggers  provide  limited 
symbolic  access  to  variables.  This  access  is  normally  to 
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variables  of  the  most  basic  program  types.  More  complex 
structures  such  as  user-defined  data  types,  stack-based 
dynamic  variables,  and  structured  arrays  are  examples  of 
data  acquisition  requiring  more  complex  handling  methods 
[15).  Observing  program  data  within  these  complicated  con¬ 
structs  requires  a  more  complex  command  language  to  be 
learned  and  designed. 

B.  Enhanced  Methods  for  Traditional  Designs 

Techniques  for  improving  the  quality  of  debugger  sys¬ 
tems  software  are  presented  in  this  section.  The  trend  is 
toward  automated  processes  with  emphasis  on  minimizing 
operator  involvement  and  responsibility.  Automating 
processes  and  minimizing  user  involvement  can  reduce  the 
time  spent  inside  the  ECL  cycle  of  Figure  4.  As  the 
development  phase  proceeds,  this  cycle  of  design  can  become 
costly  if  the  appropriate  tools  are  incorrectly  incorporated 
or  inefficiently  operated.  Reducing  time  spent  inside  this 
cycle  can  increase  productivity. 

Automating  processes  minimizes  the  amount  and  complex¬ 
ity  of  system  debugger  concepts  and  the  interface  language 
respectively.  Automating  the  systematic  approach  of  error 
isolation  and  placing  most  debugger  decisions  on  the 
host  can  relax  these  requirements.  A  more  complex 
system  design  is  required  resulting  in  an  inverse  reaction 
to  operator  involvement.  Time  normally  spent  learning 
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complicated  interface  languages  and  operational  concepts  can 
be  spent  in  the  design  stage  of  software  development  produc¬ 
ing  more  efficient  and  compact  code.  The  key  to  software 
productivity  focuses  on  minimizing  human  interfaces  (8). 

Parser  complexity  can  be  considerably  reduced  by  sim¬ 
plifying  queries  and  curtailing  responses  requiring  transla¬ 
tion.  A  reduction  in  parser  sophistication  can  simplify  a 
language's  BNF  description.  Storage  required  and  structure 
maintenance  can  be  decreased.  Assuming  the  system  is  guid¬ 
ing  the  debugger  session,  a  minimum  amount  of  information  is 
required  from  the  operator.  The  result  of  automating  the 
error  localization  approach  results  in  a  simplified  parser 
via  limited  responses  requiring  translation. 

Hindering  the  user  with  maintenance  of  source  listings 
and  memory  maps  can  be  alleviated.  The  system  can  provide 
the  user  with  information  pertinent  to  the  current  break¬ 
point  setting  under  investigation.  Sustaining  source  code 
information  can  provide  the  user  with  an  instantaneous  view 
at  any  time.  Modifications  to  the  source  code  can  be 
achieved  from  within  the  debugger  and  the  compile-link  por¬ 
tion  automated.  Standardizing  or  providing  editor  selection 
familiar  to  the  user  can  increase  performance  associated 
with  error  correction  capabilities.  The  current  trend  is 
toward  a  more  automated  approach  for  eliminating  or  relaxing 
these  requirements. 
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Providing  structures  for  sustenance  of  symbolic  infor¬ 
mation  is  imperative.  System  queries  require  familiar  terms 
to  simplify  user  interfaces.  By  automating  the  debugger 
process,  notably  the  power  to  make  simple  decisions,  the 
amount  and  complexity  of  symbolic  information  stored  can  be 
minimized.  Requirements  of  relaying  vast  amounts  of  infor¬ 
mation  to  the  user  are  no  longer  essential.  Reducing 
storage  requirements  decreases  the  complexity  of  structural 
maintenance.  The  user  is  nevertheless  provided  with  ample 
information  about  source  code  modifications  and  system 
queries  when  necessary. 

The  data  base  created  for  interrogation  should  be 
independent  of  the  source  language.  Intel  Corporation's 
PSCOPE  debugger  uses  this  technique  by  providing  a  variety 
of  compilers  for  a  single  machine  [8].  This  allows  the  user 
to  choose  the  optimum  language  for  a  particular  task.  Debug 
information  is  integrated  into  the  language  compiled,  in¬ 
dependent  of  language  selection,  to  be  used  on  a  single 
machine.  Data  base  designs  promote  language  independence  by 
expanding  the  number  of  languages  a  system  can  support. 

The  process  of  error  isolation  can  be  automated.  Per¬ 
forming  a  suitable  analysis  on  input  programs  before  debug¬ 
ging  provides  valuable  information  necessary  in  error  local¬ 
ization.  This  information  can  be  stored  with  symbolic  in¬ 
formation  determined  at  compi le- time .  Korel  [7]  uses  the 
dependence  graph  to  provide  information  pertinent  to 
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conducting  error  isolation  through  breakpoint  placement. 
User  responsibility  for  breakpoint  placement  is  no  longer 
required.  In  eliminating  breakpoint  placement,  the  user 
need  not  be  concerned  with  system  operational  concepts, 
learning  complex  interface  languages,  or  maintaining  and 
decoding  debug  information. 

C.  Summary 

The  efficiency  of  the  above  issues  affect  the  following 
consequences.  They  are  as  follows: 

(1)  Time. 

(2)  Cost. 

(3)  Performance. 

Time  is  directly  proportional  to  cost  and  inversely  re¬ 
lated  to  performance.  Those  requirements  not  executed  effi¬ 
ciently  are  time  consuming.  As  a  result,  production  costs 
are  increased.  Increasing  system  features  and  complexity 
will  result  in  high  performance.  However,  this  performance 
will  not  be  realized  until  familiarity  with  debugger  opera¬ 
tions  and  interface  languages  are  fluently  executed.  This 
orientation  process  is  lengthy  in  nature.  Minimizing  user 
involvement  reduces  overhead  time  commonly  required  for  sys¬ 
tem  familiarization.  Replacing  human  intervention  with  au¬ 
tomated  processes  is  desirable  resulting  in  increased  system 
performance  inversely  affecting  time  and  cost  issues. 
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In  summary,  those  issues  associated  with  debugger  usage 


•V.' 


I 

vr 


and  design  have  side-effects  directly  related  to  time,  cost, 
and  performance.  Efficient,  automated  operation  is  desired 
to  minimise  system  dependence  on  user  involvement. 
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Chapter  IV 


SYSTEM  DEVELOPMENT  AND  RESULTS 


Design  issues  associated  with  typical  debugger  systems 


were  presented  in  the  previous  chapter.  With  these  issues 


were  techniques  for  improving  conventional  designs  through 


process  automation.  Verification  of  these  techniques  dic¬ 


tate  the  development  of  a  prototype  system  design.  The  ob¬ 


jective  of  this  design  is  to  substantiate  these  concepts 


through  test  case  evaluation  of  the  prototype. 


The  Automatic  visual  Debugger  (AVD)  is  a  prototype  sys¬ 


tem  designed  to  comply  with  these  concepts.  The  complete 


process  of  error  localization  and  key  to  system  success  re¬ 


volves  around  automation  of  debugger  functions.  Equally  im¬ 


portant  is  the  communication  of  pertinent  information  to  the 


user.  This  is  performed  visually  by  displaying  system 


status  and  program  information  continually  throughout  the 


automated  debugging  process. 


A .  Prototype  System  Development 


Automated  systems  can  be  categorized  by  three  distinct 


characteristics : 
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(1)  Function. 

(2)  Application. 

(3)  Operational  mode. 

The  functional  classification  describes  what  capacity 
AVD  will  perform.  The  specific  function  is  source  program 
dynamic  analysis,  an  automated  tool  for  monitoring  program 
run  time  behavior.  During  the  execution  of  a  program,  cer¬ 
tain  information  is  gathered  about  source  code  behavior. 
This  information  can  be  either  used  by  the  debugging  system 
or  communicated  to  the  user. 

The  application  classi f ication  determines  that  phase  of 
program  development  the  AVD  system  will  encompass.  From  the 
beginning,  AVD  has  been  designed  to  aid  in  the  testing  and 
debugging  phase  of  program  development. 

The  operational  mode  determines  if  the  source  code  will 
be  analyzed  before  execution,  static,  or  during  execution, 
dynamic.  Static  analysis  does  not  require  program  execution 
to  determine  information  (10].  AVD  assumes  a  suitable  stat¬ 
ic  analysis  has  been  performed  before  system  execution.  This 
implies  that  the  suspect  source  code  is  free  of  compilation 
errors  and  a  suitable  program  data  base  is  generated  for  fu¬ 
ture  manipulation.  This  data  base  can  be  constructed  as  a 
dependence  graph,  symbol  table,  or  combination  of  structures 
for  information  extraction.  Dynamic  analysis  requires 
source  code  execution  to  do  an  adequate  investigation  of 
program  characteristics  [10],  As  stated  by  the  functional 
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classification  and  reinforced  here,  AVD  is  a  dynamic 
analysis  system. 

The  prototype  system  was  designed  and  written  in  the  C 
programming  language.  In  addition,  the  prototype  system  was 
developed  on  the  Unix  operating  system.  Both  C  and  Unix  are 
highly  portable  and  flexible  producing  compact  and  efficient 
code . 

The  Unix  operating  system  is  available  on  many 
machines,  from  smaller  microcomputers  and  minicomputers  to 
the  largest  mainframes.  Unix  is  available  on  many  different 
machines  and  is  therefore  termed  portable  by  the  scientific 
community.  This  criteria  is  important  for  AVD  to  meet  the 
specific  requirement  of  flexibility  presented  in  Chapter 
III.  Portability  is  largely  because  the  C  programming 
language  with  about  95%  of  the  Unix  operating  system  written 
in  C  (12).  A  novel  set  of  features,  utilities,  and  system 
portability  are  reasons  for  Unix  popularity  and  success. 
Multitasking  and  shell  functions  allow  more  productivity 
permitting  AVD  to  do  functions  (nested  processes)  not  nor¬ 
mally  allowed. 

The  C  programming  language  is  a  modern  systems 
language.  The  C  language  has  high-level  constructs  for  ef¬ 
ficient,  modular  programming  in  addition  to  low-level  func¬ 
tions  for  manipulating  data  at  the  machine  level  [12]. 
Low-level  abilities  allow  specification  of  details  in  user 
programs  to  achieve  maximum  computer  efficiency.  High-level 
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abilities  promote  programming  efficiency  by  concealing  de¬ 
tails  of  the  computer's  architecture  [5].  High  and  low  lev¬ 
el  traits  make  C  an  excellent  language  for  AVD  processing. 
C  can  be  used  to  write  machine-independent  programs,  has 
high  level  features  for  flexibility,  and  can  still  be  used 
for  systems  programming.  These  features  make  C  portable, 
standard,  and  powerful.  Programs  written  in  C  are  fast  and 
require  small  amounts  of  storage.  Powerful  tools  are  built 
into  the  C  language  for  many  functions,  specifically  string 
processing,  which  is  much  needed  by  AVD.  Teamed  with  Unix, 
requirements  relating  to  flexibility  and  machine  indepen¬ 
dence  are  easily  done  by  the  AVD  system.  Appendix  B  con¬ 
tains  the  prototype  system  software. 

The  AVD  system  consist  of  a  three  phase  process.  These 
phases  constitute: 

(1)  Initialization. 

(2)  Error  localization  processing. 

( 3 )  Te  rminati on . 

Each  phase  of  operation  will  be  comprehensively  covered.  A 
condensed  version  of  the  error  localization  cycle  is  shown 
in  Figure  5. 

B.  Initialization  Phase 

The  initialization  phase  of  AVD  is  graphically  present¬ 


ed  in  Figure  6. 
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Figure  5:  Error  Localization  Cycle 
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The  command  data  base  is  comprised  of  Unix  commands. 
These  commands  are  principally  used  for  sustaining  current 
object  files  after  source  file  modifications.  Modifications 
can  be  executed  by  the  user  or  AVD.  User  modifications  to 
source  code  occur  normally  after  errors  are  located.  AVD 
modifications  are  because  breakpoint  placement  requires  con¬ 
tinuous  monitoring.  Additional  commands  are  provided  for 
display,  editing,  and  other  facilities.  The  command  data 
base  is  easily  expanded  to  include  any  commands  desired.  Of 
greater  significance  is  the  ability  to  automatically  execute 
these  commands  from  within  the  debugging  process.  The  C  li¬ 
brary  function  SYSTEM  provides  for  executing  Unix  commands 
within  the  AVD  debugging  phase.  These  two  factors  favorably 
influence  productivity. 

The  input  command  line  is  decoded  to  obtain  information 
necessary  for  maintaining  and  modifying  the  correct  source 
file.  The  command  line  is  scanned  and  relevant  information 
extracted.  This  information,  normally  source  code  filename, 
is  stored  and  concatenated  with  the  appropriate  Unix  com¬ 
mands  for  future  applications.  The  command  line  must  be 
scanned  if  multiple  module  names  exist  for  a  single  program 
design.  This  eases  the  programmer  restriction  of  single 
module  program  designs  by  allowing  independent  compilations 
of  separate  modules. 

The  display  incorporates  CURSES  [14],  a  screen  oriented 
program  package  for  interfacing  AVD  to  the  terminal  display. 
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During  the  initialization  phase,  arrangements  are  made  to 
incorporate  CURSES.  Library  routines  are  called  to  initial¬ 
ize  the  screen  and  configure  keyboards  dependent  on  program 
specifics  and  hardware  used.  Display  functions  will  be  dis¬ 
cussed  thoroughly  in  Section  C.  For  now  it  is  only  neces¬ 
sary  to  know  that  some  initialization  occurs  to  incorporate 
displays  to  provide  a  better  user  interface  and  that  this  is 
the  logical  place  for  that  initialization  to  occur. 

Continuing  through  the  initialization  phase,  efforts 
are  now  focused  for  final  preparations  of  the  source  code. 
As  stated  earlier,  it  is  assumed  that  a  suitable  static 
analysis  has  been  completed  on  the  source  code.  However, 
for  program  usage  the  source  code  is  compiled  and  linked 
with  the  resultant  object  code  placed  in  the  default  file, 
A. OUT.  Following  these  commands,  AVD  issues  the  appropriate 
Unix  commands  for  insuring  all  object  files  are  current. 
These  filenames  are  determined  from  the  command  line  before 
execution.  It  is  important  to  remember  that  these  functions 
are  being  executed  automatically  without  user  intervention. 

Equally  important  is  the  input  of  program  source  code 
for  future  display.  This  eliminates  the  lengthy  listings  and 
memory  maps  that  are  ordinarily  used  in  debugging  sessions. 
The  procedure  LEXICON  completes  the  task  of  inputting  the 
program  source  code.  LEXICON  then  calls  the  C  library  func¬ 
tion  MALLOC  to  acquire  this  code.  MALLOC  dynamically  allo¬ 
cates  memory  for  each  line  of  source  code.  An  array  of 
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pointers  independently  references  each  line  of  code. 

The  final  stage  of  initialization  is  program  data  base 
construction.  The  program  data  base  is  built  for  future  in¬ 
formation  extraction.  Algorithms  obtain  information  by 
scanning  the  source  and  object  code  files.  These  algorithms 
should  be  capable  of  examining  any  type  source  and  producing 
a  common  data  base.  The  program  data  base  is  a  dependence 
graph  or  similar  structure  and  provides  information  to  AVD 
necessary  to  localize  a  program  error.  AVD  assumes  an  ap¬ 
propriate  data  base  exist  before  program  execution. 

The  initialization  phase  automates  many  tasks  normally 
considered  as  the  user's  responsibility.  The  task  of  com¬ 
piling  and  linking  is  controlled  by  AVD.  The  task  of  main¬ 
taining  current  listings  is  automated  and  source  code  infor¬ 
mation  is  provided  to  the  user  on  request.  The  automation 
of  these  two  tasks  eliminates  the  need  for  procedures  that 
are  frequently  used  throughout  typical  debugging  sessions. 
Automation  of  these  processes  reduces  wasted,  time  and  in¬ 
creases  system  performance. 

C.  Error  Localization  Processing  Phase 

Figure  7  graphically  represents  the  error  localization 
processing  phase. 

The  error  localization  processing  phase  is  an  infinite 
loop.  The  loop  is  terminated  by  issuing  an  EXIT  command. 


In  addition,  system  prompts  provide  an  alternate  means  of 
terminating  the  debug  session. 

Initially  the  program  is  executed  and  results  displayed 
to  the  user.  AVD  (Automatic  Visual  Debugger)  queries  the 
user  to  determine  if  these  results  are  correct.  Dependent 
on  the  user's  response  one  of  two  paths  may  be  taken  at  this 
time.  The  user  may  immediately  exit  AVD  or  enter  a  debug 
session  for  error  localization.  Exit  may  be  desired  if  pro¬ 
gram  results  are  correct.  The  user  may  also  specify  a  dif¬ 
ferent  variable  for  inspection  if  so  desired.  System 
prompts  are  provided  for  supporting  these  options. 

The  second  path  leads  to  a  debugging  session  with  AVD. 
Assuming  the  results  are  incorrect,  the  first  stage  of  au¬ 
tomatic  visual  debugging  occurs.  AVD  queries  the  user  for 
the  variable  suspected  of  being  in  error.  A  flag  setting 
prevents  the  system  from  continually  querying  the  user  for 
suspect  variables.  This  flag  permits  a  query  only  when 
needed.  All  locations  within  the  source  for  each  program 
variable  are  recorded  in  a  data  base.  In  addition  to  vari¬ 
able  locations,  information  about  variable  usage  may  be 
recorded.  The  sum  of  this  information,  location  and  usage, 
assist  AVD  in  the  critical  placement  of  breakpoints.  For 
example,  a  suspect  variable  may  be  inside  a  loop.  Should 
the  breakpoint  be  placed  to  observe  the  suspect  variable 
with  each  loop  iteration  or  at  the  loop  conclusion?  Algo¬ 
rithms  exist  to  resolve  these  issues  [7).  Traversal  methods 


scan  the  program  data  base  to  extract  information  about-  the 
suspect  variable.  Backtracking  is  an  efficient  method  for 
traversing  the  program  data  base  and  acquiring  information 
to  assist  these  algorithms  in  determining  breakpoint  loca¬ 


tion. 


To  accurately  place  a  breakpoint  requires  three  steps. 
Step  one  scans  the  program  data  base  for  desired  breakpoint 
location  and  suspect  variable  usage.  Algorithms  incorporate 
this  information  to  resolve  issues  and  determine  exact 
breakpoint  location.  Step  two  physically  places  the  break¬ 
point  by  arming  system  hardware  to  recognize  certain  condi¬ 
tions.  Step  three  updates  all  files  if  necessary  and  exe¬ 
cutes  the  desired  breakpoint  setting. 

AVD  simulates  these  three  steps  associated  with  break¬ 
point  placement  by  executing  the  following  operations. 
These  operations  occurred  at  points  in  time  corresponding  to 
a  genuine  debugging  process.  When  breakpoint  placement  was 
necessary  and  at  the  appropriate  time,  the  current  process 
of  the  debugging  system  was  suspended.  A  subprocess  was 
spawned  to  emulate  typical  breakpoint  placement.  The  subpro¬ 
cess  can  be  visualized  as  time  spent  to  normally  place  a 
breakpoint  in  a  conventional  system.  The  spawning  process 
was  begun  by  the  C  library  function  SYSTEM.  Corresponding  to 
step  one  above,  the  program  data  base  is  traversed  to  deter¬ 
mine  information  about  breakpoint  placement.  Corresponding 
to  step  two,  PRINTW  statements  are  incorporated  to  simulate 


arming  hardware  to  recognize  breakpoint  settings.  A  PRINTW 
statement  represents  a  typical  breakpoint  and  is  placed  at 
locations  determined  by  traversing  the  program  data  base. 
The  EMACS  editor  assists  in  providing  a  means  of  inserting 
these  statements  into  the  program  source.  Corresponding  to 
step  three,  the  source  file  is  updated  by  executing  a  Unix 
MAKE  command.  MAKE  is  capable  of  compiling  and  linking 
files  based  on  their  prior  history.  MAKE  operates  on  a  de¬ 
fault  file  called  MAKEFILE.  This  file  can  easily  be  input, 
modified  to  include  additional  modules  detected  in  the  com¬ 
mand  line,  and  output  for  continued  usage.  On  executing  the 
MAKE  command,  the  subprocess  is  terminated  and  the  suspended 
process  returned  to  active  status.  The  second  half  of  step 
three  involves  executing  the  program  up  to  the  breakpoint 
location.  This  portion  is  provided  as  an  option  inside  the 
display  trace. 

The  subprocess  succeeds  in  breakpoint  placement  by 
scanning  the  program  data  base,  physically  placing  the 
breakpoint,  and  performing  file  maintenance.  Automating 
these  three  functions  spares  the  user  of  tedious  tasks  and 
provides  a  simplistic  approach  toward  the  breakpoint  place¬ 
ment  process.  These  functions  would  be  combined  into  a  sin¬ 
gle  procedure  for  a  genuine  debugging  system  as  demonstrated 
by  Korel  [ 7  ]  . 

At  this  stage  of  operation  a  breakpoint  has  been  suc¬ 
cessfully  placed  and  AVD  enters  the  trace  display  procedures 
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shown  in  Figure  7.  Now  the  AVD  system  incorporates  CURSES 
[14].  CURSES  is  a  powerful  programming  package  capable  of 
enhancing  the  display  interface.  This  is  done  through  mul¬ 
tiple  windows,  text  functions  such  as  highlighting  and  bold 
type,  and  controlling  cursor  movements.  AVD  uses  CURSES  to 
create  a  two  window  concept.  These  windows  provide  trace 
display  information  and  expert  system  guidance.  The  first, 
TRACE_WIND0W,  provides  the  user  with  information  about 
breakpoint  placement,  suspect  variable  identification,  and 
next  choice  of  system  command.  The  second,  STDSCR,  is  an 
expert  system  guidance  window.  STDSCR  provides  information 
transfer  between  the  user  and  AVD  through  system  queries  and 
user  responses.  This  is  the  window  for  normal  operations 
outside  the  trace  display  procedures. 

Display  operations  are  entirely  controlled  by  procedure 
WINDOWS.  All  situations  involving  command  response  are 
highlighted  for  emphasis  and  furnished  to  the  user  in  menu 
fashion.  The  menu  offers  command  choices  corresponding  to  a 
specific  alphanumeric  key  and  is  displayed  to  the  user  for 
selection.  These  features  assist  the  user  in  the  decision 
making  process  by  providing  a  list  of  commands  allowed  at 
specific  points  in  the  debugging  phase.  This  eliminates  the 
necessity  to  learn  system  commands  and  operations. 

On  entering  the  trace  display,  WINDOWS  provides  a  trace 
display  menu.  Three  options  are  provided:  exit,  observe 
trace  settings,  or  execute  the  current  breakpoint  setting. 
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The  trace  display  menu  can  be  easily  expanded  to  include  ad¬ 
ditional  commands  as  desired.  The  exit  command  is  self- 


explanatory.  Pressing  the  alphanumeric  key  Q  will  end  the 
AVD  debug  session  and  return  to  the  host  operating  system. 

The  execute  command  allows  the  user  to  run  the  program 
with  the  current  breakpoint  setting.  Pressing  the  al¬ 
phanumeric  key  X  provides  this  function.  Starting  this 
function  terminates  the  trace  display  window,  re-enters  the 
standard  screen,  and  executes  current  program  settings.  The 
error  localization  phase  is  repeated. 

The  third  option  allows  observance  of  trace  settings. 
The  trace  settings  include  display  of  breakpoint  location 
and  suspect  variable.  The  current  breakpoint  location  is 
highlighted  and  displayed  to  the  user.  Source  statements 
surrounding  the  breakpoint  are  displayed  in  conventional 
video.  This  emphasizes  the  breakpoint  setting  and  orients 
the  user  to  breakpoint  location  within  the  source  code.  The 
variable  suspected  of  being  in  error  is  highlighted  and 
displayed.  Pressing  the  alphanumeric  key  C  executes  this 
option.  Terminating  this  option  returns  the  user  to  the 
trace  display  menu.  The  user  is  therefore  allowed  to  ob¬ 
serve  trace  settings  before  executing  the  program. 

Each  window  is  provided  with  a  message  library.  These 
libraries  contain  queries  executed  within  their  respective 
windows.  Each  window  contains  a  set  of  specific  queries  and 
messages  transmitted  to  user.  Procedure  PROCESS_MESSAGE 
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consists  of  messages  in  the  STDSCR  window  and  include  those 
used  in  expert  system  guidance.  These  entail  queries  about 
suspect  variable  identification,  correctness  of  results,  and 
others  to  determine  needed  information.  Procedure  HIGHLIGHT 
consists  of  messages  in  the  window  TRACE_WIND0W  and  include 
those  used  during  the  trace  display  portion  of  AVD.  These 
entail  options  about  program  execution  and  trace  display 
viewing.  The  messages  in  this  library  are  highlighted  for 
emphasis.  Each  library  can  be  easily  expanded  to  accommo¬ 
date  several  messages.  However,  crowding  the  display  with 
numerous  messages  tends  to  increase  user  frustration  and 
confusion. 

The  error  localization  processing  phase  is  complete. 
Guidance  through  this  phase  was  described  above.  Additional 
techniques  for  automation  are  provided.  Selecting  the 
breakpoint  location,  placing  the  breakpoint,  and  executing 
the  program  to  provide  breakpoint  information  was  described. 
Providing  command  selection  during  the  error  localization 
phase  eliminates  the  need  for  learning  system  commands  and 
concepts.  Automating  these  processes  increases  productivity 
oy  minimizing  user  involvement. 

D.  Termination  Phase 

Figure  8  graphically  represents  the  termination  phase. 
In  the  WINDOWS  procedure,  mechanisms  exist  to  detect 
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Figure  8:  Termination  Phase 
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and  conclude  the  error  localization  process.  These  algo¬ 
rithms  base  their  decisions  on  information  acquired  from 
correlating  user  queries  and  data  base  data.  Error  isola¬ 
tion  leads  to  procedures  for  terminating  the  AVD  session  and 
displaying  final  results.  Procedure  LOCALIZED  is  responsi¬ 
ble  for  displaying  final  results. 

Before  displaying  the  source  statement  containing  the 
error,  LOCALIZED  executes  calculations  to  display  surround¬ 
ing  lines.  This  orients  the  user  to  the  error  location 
within  the  source  code.  The  line  number,  source  code  state¬ 
ment,  and  surrounding  lines  are  displayed.  The  suspect 
statement  is  highlighted  for  emphasis. 

Transmitting  the  information  to  the  user  completes  the 
error  localization  cycle.  The  final  task  is  to  reset  termi¬ 
nal  hardware  and  displays  to  their  original  settings.  This 
is  done  by  executing  the  appropriate  commands  to  exit  the 
CURSES  package.  The  termination  of  CURSES  results  in  the 
exit  of  AVD  and  return  to  the  host  operating  system. 

E.  Prototype  System  Verification 

The  prototype  system  was  verified  by  designing  three 
typical  program  test  cases.  Each  test  case  had  specific  er¬ 
rors  deposited  in  the  source  code  to  be  detected.  These  er¬ 
rors  were  different  for  each  test  case.  Source  code  for 
test  case  programs  are  located  in  Appendix  A. 
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Test  case  one  is  a  sequential  program  without  control 
constructs  or  procedure  calls.  This  suggest  a  data  depen¬ 
dence  relationship  between  instructions  [7],  The  program 
function  is  to  calculate  an  employees  net  pay.  The  error 
to  be  detected  is  a  numerical  computation;  addition  is  shown 
but  multiplication  is  required.  The  statement,  RP  -  RH  + 
PR,  should  have  been  RP  -  RH  *  PR.  This  was  determined  by 
scanning  the  program  data  base  and  determining  that  input 
values  to  RP  should  be  verified.  AVD  places  breakpoints  in 
the  program  to  determine  RH  and  PR  correctness.  On  reaching 
these  breakpoints  queries  are  made  to  the  user  to  determine 
variable  status.  Both  variables  are  found  to  be  correct 
suggesting  RP  was  calculated  improperly.  AVD  successfully 
isolates  the  error  to  a  single  statement  and  transmits  this 
information  to  the  user.  This  test  case  is  similar  to  one 
use  by  Korel  [ 7  ]  . 

Test  case  two  contains  control  constructs  and  is  more 
complex  in  nature.  All  data  dependences  are  possible.  Data 
is  admitted  from  the  standard  input  (monitor)  and  a  record 
kept  of  the  number  of  lines  and  characters  transmitted.  The 
error  to  be  detected  is  an  initialization  anomaly.  The 
statement,  NUM_OF_LINES  -  1,  should  have  been  NUM_OF_LINES  - 
0.  The  error  is  successfully  isolated  by  placing  break¬ 
points  at  variable  NUM_OF_LINES  locations.  The  first  break¬ 
point  location  is  in  a  control  construct.  AVD  algorithms  us¬ 
ing  information  from  the  program  data  base  resolve  issues  of 
breakpoint  placement.  It  is  determined  that  the  breakpoint 
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should  be  placed  within  the  construct.  This  will  break  and 
report  the  NUM_OF_LINES  value  with  each  iteration.  Queries 
to  the  user  verify  that  the  variable  is  initially  incorrect 
after  one  iteration.  AVD  traverses  the  program  data  base 
for  checkpoints  and  determines  usage  at  one  additional  posi¬ 
tion.  AVD  isolates  this  location  and  through  user  queries 
determines  the  variable  was  initialized  incorrectly.  These 
results  are  transmitted  to  the  user. 

Test  case  three  is  a  bubble  sort  routine.  The  most 
complicated  of  the  three,  this  test  case  contains  both  con¬ 
trol  constructs  and  procedure  calls.  Again,  all  three  data 
dependences  are  possible.  The  error  detected  is  caused  from 
improper  variable  usage.  The  statement,  TEMP  -  ARRAY  [IN¬ 
DEX],  should  have  been  TEMP  -  ARRAY  [INDEX_1].  Through  a 
series  of  placing  breakpoints  and  issuing  user  queries,  in¬ 
formation  is  collated  and  a  conclusion  determined.  AVD  suc¬ 
cessfully  localizes  the  error  location  and  transmits  the 
results  to  the  user. 

Test  case  three  demonstrates  the  ability  of  AVD  to 
operate  on  multiple  module  programs.  Case  three  consists  of 
two  modules.  Modifications  to  either  module  results  in  suc¬ 
cessful  error  localization.  AVD  permits  the  observance  of 
module  listings,  breakpoint  placement  within  either  module, 
and  insures  that  the  appropriate  files  were  correctly  main¬ 
tained.  As  stated  earlier  MAKEFILE  can  be  modified  to  in¬ 
clude  several  modules. 


The  AVD  system  successfully  isolates  each  error  for  all 
test  cases.  Computational  syntax  (operator),  variable  ini¬ 
tialization,  and  variable  usage  errors  are  detected.  Loca¬ 
tion  of  each  error  is  then  transmitted  to  the  user.  AVD 
successes  are  from  incorporating  methods  developed  in 
Chapter  III  into  the  prototype  system  of  Chapter  IV. 
Automating  processes  is  the  key  to  a  more  productive  debug¬ 
ging  environment. 
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Chapter  V 


CONCLUSIONS  AND  RECOMMENDATIONS 


A.  Conclusions 

This  research  has  concentrated  on  process  automation  to 
create  a  simplified  debugging  environment.  Methods  were 
presented  to  accomplish  automation.  These  methods  focused 
on  automating  tasks  normally  performed  by  the  user.  Tech¬ 
niques  suggested  increase  system  performance  by  deceasing 
cost  and  time  factors  associated  with  conventional  systems. 

Each  phase  of  the  error  localization  processing  cycle 
uses  automation.  The  initialization  phase  exploited  automa¬ 
tion  in  program  preparation  and  source  code  management. 
Compiling  and  linking  operations  merged  to  form  a  single 
task  to  prepare  source  code  for  debugger  investigation.  The 
aforementioned  task  is  applied  throughout  the  error  locali¬ 
zation  process.  The  source  file  was  input  for  display  pur¬ 
poses  and  a  program  data  base  built  for  future  interroga¬ 
tion.  Each  task  supported  automated  processes  of  succeeding 
phases.  The  initialization  phase  primary  responsibility  is 
to  prepare  source  code  for  future  manipulation  and  provide 
support  for  automated  processes.  This  responsibility  was 
met  by  the  initialization  phase. 
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The  error  localization  processing  phase  is  completely 
automated.  The  phase  itself  is  driven  by  automation  through 
system  queries.  Responding  to  these  queries  assist  the  pro¬ 
totype  system  in  the  decision  making  process.  Within  the 
cycle  are  additional  automated  processes  for  breakpoint 
placement  and  display  functions. 

The  process  of  breakpoint  placement  was  automated.  A 
program  data  base  was  constructed  by  performing  a  flow 
analysis  of  the  source  code  during  the  initialization  phase. 
The  program  data  base  was  interrogated  and  information  ex¬ 
tracted.  This  information  assists  algorithms  in  drawing 
conclusions  about  breakpoint  placement.  The  breakpoint  was 
then  automatically  placed  within  the  source  code  and  execut¬ 
ed  on  the  users  request. 


A  display  provided  observance  of  different  debug  data. 
The  display  section  was  completely  automated  and  provided 
status  information  to  the  user. 

The  termination  phase  displays  concluding  data  and  ter¬ 
minates  the  debug  session,  returning  control  to  the  host 
operating  system.  All  hardware,  including  displays  and  key¬ 
boards,  are  reset  to  their  original  settings.  The  termina¬ 
tion  phase  is  completely  automated  and  internal  operations 
concealed  from  the  user. 

The  keyword  is  automation.  From  the  above  summations, 
the  prototype  system  met  all  research  objectives.  A 
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framework  was  provided  for  future  debugger  designs  and  pro¬ 
cess  automation  used  to  create  a  simplified  debugging  en¬ 
vironment  . 

B.  Recommendations 


The  prototype  system  is  a  model  for  future 
designs.  Many  features  demonstrated  could  easily 
porated  into  current  debugger  systems.  Inclusion 
facilities  could  provide  a  significant  increase  i 
system  performance. 


debugger 
be  incor- 
of  these 
n  current 


Many  areas  of  the  prototype  system  have  potential  for 
future  research.  The  system  provided  was  a  prototype  for 
demonstrating  new  and  innovative  ideas.  The  use  of  a  pro¬ 
gram  data  base  was  demonstrated.  A  universal  program  data 
base  is  required  to  make  the  prototype  system  flexible. 
Research  into  the  area  of  a  universal  program  data  base 
could  prove  challenging.  Automatic  breakpoint  placement  was 
demonstrated.  This  area  could  be  further  developed  with  em¬ 
phasis  place  on  algorithm  design.  Each  of  these  areas  could 
be  a  basis  for  further  investigation.  Completion  of  these 
tasks  could  help  make  the  Automatic  Visual  Debugger  (AVD)  a 
reality. 
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APPENDIX  A 


TEST  CASES 


/* 

**  easel:  financial  program 

V 

iinclude  <stdio.h> 

main(  ) 

{ 

FILE  * f i 1 e ; 

float  RH,  OH,  PR,  FTR ,  NE ,  RP,  OP,  GP,  FTW,  STW,  SSTW, 
NP,  input_data[ 5  ]  ; 
int  count; 

file  -  fopen( "easel .dat"  ,  "r"); 

while  ( f scanf ( f ile ,  "%f",  &input  data[count])  l-  EOF) 
++count;  ~ 

RH  -  input_data[ 0 ] ; 

OH  -  input_data [ 1 ]  ; 

PR  -  input_data[ 2 j ; 

FTR  -  input_data{ 3 j ; 

NE  -  input_data ( 4 j ; 

RP  -  RH  +  PR;  /*error:  RP  -  RH  *  PR*/ 

OP  -  2  *  OH  *  PR; 

GP  -  RP  +  OP; 

FTW  -  (GP  -  10  *  NE)  *  FTR; 

STW  -  GP  *  0.05; 

SSTW  -  GP  *  0.06; 

NP  -  GP  -  FTW  -  STW  -  SSTW; 

printf  ("net  pay  ■  %f0,  NP); 
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/* 

**  case2:  file  line  and  character  count 

*/ 

♦include  <stdio.h> 

♦define  CTRL(c)  ('c'  &  037  ) 

main  (  ) 

[ 

int  nura_of_chars ,  num_of_lines ; 
char  in_char; 

num_of_chars  -  0; 

num_of_lines  -  1;  /*error:  -  0*/ 

while  ((in  char  -  getcharO)  i-  CTRL(d)) 

{ 

if  (in_char  1-  '0) 

++num_o f _cha r s ; 
else 

++num  of  lines; 

}  ~  ” 

printf  ( "Oum_of_chars  -  %d0,  num_of_chars ) 
printf  ( "num_of_lines  »  %d0,  num  of  lines) 


} 


/* 

**  case3:  bubble  sort  routine 
*/ 

♦include  <stdio.h> 

♦define  amount  10 

main(  ) 

{ 

FILE  * f i 1 e ; 

int  array [ amount ) ,  index,  index_l,  temp, 
number,  temp_index; 

file  -  fopen( "case3 . dat"  ,  "r"); 

index,  temp  •  0; 

while  ( fscanf ( f ile ,  "%d",  &ar ray [ index ] )  I-  EOF) 
++index ; 

temp  index  -  index; 

— in3ex; 

while  (index  >  1) 

{ 

for  (index_l  -  0;  index_l  <  index;  ++index  1) 

{ 

if  ( array [ index ]  <  arrayfindex  1)) 

{ 

temp  -  ar ray { index ] ;  /*error:  index_l*/ 
array[index  1]  -  array[ index ] ; 
arraylindexT  ■  temp; 

} 

} 

—  index ; 

} 

for  (index_l  -  0;  index_l  <  temp  index;  ++index_l) 
printf  ("-■>  Id  0,  ar ray [ index_T] ) ; 

message();  /*to  prove  'make'  works  in  all  cases*/ 

}  /*main*/ 


APPENDIX  B 


PROTOTYPE  SYSTEM  SOURCE  CODE 


#include  <curses.h> 

tdefine  LINE_LENGTH  80 
tdefine  FILE  LENGTH  50 


static 

int 

case_l( ] 

-  {28,  22, 

20, 

16,  14,  0} 

static 

int 

case_2 [ ] 

-  {16,  9, 

0}  ; 

static 

int 

case_3[ j 

-  {27,  25, 

13, 

0}; 

static 

char 

strl  [  20 ] 

-  "cat  " ; 

static 

char 

str2( 20  ] 

*  "emacs 

»♦  . 
t 

static 

char 

str 3 [ 20 ] 

m  "vi  "  ; 

static 

char 

str 4  [  20 ] 

-  "make  " 

• 

/ 

static 

char 

str5[  35] 

-  "cc  -c 

»  . 

! 

static 

char 

str6[ 35] 

-  "  c  c  "  ; 

WINDOW  ‘trace  window; 


char  ‘line  ptr [ FILE_LENGTH ] ; 
char  variable! 15 ] ; 
int  flag,  ‘selection,  msg_no; 
int  beg_line,  end_line,  y_coord; 
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main(argc,  argv) 
int  argc; 
char  *argv( ] ; 

{ 

char  response [ 15 ]  ; 
initialize( &argc,  argv); 

mvprintw(20,  0,  "Debugging  program  %s",  argv[l]); 

mvprintw(21,  0,  "Preparing  program  Is",  argv(l)); 
system( str 5 ) ; 
system( str 6 ) ; 

lexicon( argv) ; 
ref resh(  )  ; 

sleep( 5 )  ; 

while ( 1 ) 

{ 

rasg_no  -  7;  process_message ( &msg_no ,  argv); 
system( "a . out" ) ; 

msg_no  -  8;  process_message ( &msg_no ,  argv); 

gets ( response ) ; 
keyboard_interface( response)  ; 

} 

} 


■%  - 1 

>.-■ 


■  v 
>  »■ 


keyboard_interface( string) 
char  *  string! ] ; 


if  (  1  ( strcmp( "no" ,  string))) 

{ 

if  (flag) 

{ 

msg_no  -  1;  process_message ( &msg_no )  ; 
gets ( variable ) ; 
flag  -  FALSE; 

} 

msg_no  -  2;  process_message ( &rasg_no ) ; 

system( str2 ) ; 

systera{ "make  -f  case"); 

clear ( stdscr ) ; 

windows ( )  ; 

} 

else  if  ( ! ( strcmp( "yes" ,  string))) 

{ 

msg_no  -  3;  process_message ( &msg_no )  ; 
gets( string)  ; 

if  (  !  ( strcmp( "yes" ,  string))) 

{ 

msg_no  -  4;  process_message ( &msg_no ) ; 
e  x  i  t  (  )  ; 

} 

else 

{ 

msg_no  -  5;  process__message  (  &msg_no )  ; 
flag  -  TRUE; 

return ( keyboa rd_inte r f ace ( string) ) ; 

} 

) 

else  if  ( l ( strcmp( "exit" ,  string))) 

{ 

msg_no  -  6;  process_message ( &msg_no ) ; 
exi t  (  ) ; 

} 


lexicon} source  file) 
char  *source__fTle [  ] ; 

{ 

FILE  *file; 

char  line [LINE  LENGTH); 
char  *install(7; 

file  -  fopen{ source_f ile[  1 )  ,  "r"); 

while  ( f gets ( line ,  LINE_LENGTH ,  file)) 
install  ( line ) ; 

mvprintw(22,  0,  "Installed  program  %s0, 
source  f ile[ 11); 

} 


".V.VV'.V 
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char  ‘install ( line ) 
char  ‘line; 

{ 

static  int  x-0; 
char  *malloc(  )  ; 
char  *string_ptr; 

if  (string_ptr  -  malloc( strlen( line )  +  1)) 

{ 

strcpy ( string_ptr ,  line); 
line_ptr(x]  -  string_ptr; 

++x ; 
return; 

) 

mvprintw  (22,  0,  "out  of  memoryO); 
ref resh( ) ; 
exit(  )  ; 

} 


a 


|i 
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initializef  num_of_args ,  source_file) 
int  *num_of_args ; 
char  ‘source  filet  1; 


. 

i 

i 


{ 

char  *ob ject_f ile ; 


strcatt  strl , 
strcat( str2 , 
strcatt  str 3 , 
strcat ( str4 , 

flag  -  TRUE; 


source_f i 1 e [ 1 ] ) 
source_f i le [ 1 ) ) 
sour ce_f i le [ 1 ] ) 
source  filet  1  ] ) 


if  (!( strcmpt "easel . c" ,  source  filefl]  )  )  ) 

{  selection  -  case_l;  object_fTle  -  "easel. o"; 
else  if  ( 1 ( strcmpt "case2 . c" ,  source_f ile [ 1 ] ) ) ) 
{  selection  -  case_2;  object_file  -  "case2.o"; 
else 

{  selection  -  case_3;  object_file 
-  "case3.o  case3.1.o";  } 
strcat(str6,  object_f ile ) ; 

if  (*num_of  args  l-  3) 
strcat { strS,  source_f ilfe ( 1 ] ) ; 
else 
{ 

strcat(str5,  source^f ile [ 1 ] ) ; 
strcat ( str5  ,  "  "  )  ; 
strcat(str5,  source  file[2J); 

i  ~ 


initscr (  ) ; 
nl(  )  ; 
echo (  )  ; 
ermode (  )  ; 


clear ( stdscr ) 

} 


process_message ( msg ,  sour ce_f i le ) 
int  *msg; 

char  *source_file[ ] ; 

( 

if  (  (  *msg  ! ■  1)  &&  (  *msg  ! -  8)  &&  ( *msg  !-  9)) 
clear ( stdscr )  ; 

move ( 22  ,  0  )  ; 

switch ( *msg ) 

{ 

case  1: 

printw( "Enter  variable  suspect  of  being 
in  error:  "); 

break ; 
case  2: 

printw( "Inserting  breakpointsO); 
break ; 
case  3: 

printw( "Terminate  JEANS  session?  "); 
break ; 
case  4: 

printw( "JEANS  session  concluded  !  0  )  ; 
break ; 
case  5: 

mvprintw(21,  0,  "Assume  you  wish  to 

look  at  another  variable!"); 

break ; 
case  6: 

printw( "JEANS  session  concluded  !  0  )  ; 
endwin( ) ; 
break  ; 
case  7  : 

pnntw(  "Executing  program  %s0,  source_f  ile  [  1  ]  ) 
break ; 
case  8: 

printw( "were  program  results  correct?  "); 
break; 
case  9: 
standout ( ) ; 

mvpr intw( y_coord ,  0,  "Line  %d:  %s", 

♦selection,  line_ptr( *selection) ) ; 
standend( ) ; 

} 

ref  resh{ ) ; 

} 


windows ( ) 


{ 

int  count,  action,  display_code ; 
noecho ( )  ; 

trace_window  -  newwin{ LINES ,  COLS,  0,  0); 

for  (  ; ; ) 

{ 

ref resh(  )  ; 

wmove ( trace_window ,  12,  13); 

display_code  -  1;  highlight ( &display_code ) ; 

wmove ( trace_window,  23,  0); 
wref resh( trace_window) ; 

action  -  getch(  )  ; 
switch( action) 

{ 

case  ' c ' : 

werase( trace_window ) ; 

wmove ( trace_window,  20,  20); 

display_code  -  2;  highlight! &display_code ) ; 

beg_line  -  *selection  -  5; 
end_line  -  *selection  +  3; 

y_coord  -  3; 

for  (;  beg  line  <«  end_line;  ++beg  line) 

{ 

if  (beg_line  !-  *selection) 
mvwprintw( trace_window,  y  coord,  5, 

"%s",  line__ptr[Beg_line]  )  ; 

else 

{ 

display  code  -  3;  hi ghl ight ( &di splay  code) 

} 

++y  coord; 

}  ' 

display_code  ■  4;  highlight( 4display_code ) ; 

wmove ( trace_window,  15,  0); 
for  (count  -  0;  count  <  COLS;  count++ ) 
waddch( trace_window,  '-'); 

wmove ( t race_window ,  23,  0); 
touchwin( trace_window) ; 
wref resh( trace  window); 


while  ((action  -  getchU) 

touchwin( stdscr )  j 
break ; 

case  ' x ' : 

++selection ; 
if  (*selection  —  0) 
local i zed ( ) ; 
move ( 23 ,  0 ) ; 
clrtoeol ( ) ; 
touchwin( stdscr )  ; 
echo  (  )  ; 
ref resh(  )  ; 
return ; 

case  'q'  : 
move (23,  0); 
clrtoeol ( ) ; 
touchwin( stdscr ) ; 
echo(  )  ; 
ref resh( ) ; 

endwin( trace_window) ; 
endwin( ) ; 
exit( 0 ) ; 
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localized(  ) 

{ 

static  int  value  ■  9; 

— selection; 
if  (‘selection  --  14) 
selection  -  selection  -  2; 
else  if  (‘selection  --  13) 
selection  -  selection  -  1; 

beg_line  -  ‘selection  -  5; 
end_line  -  ‘selection  +  3; 

clear ( stdscr ) ; 

y_coord  -  7; 

for  (;  beg_line  <-  end_line;  ++beg_line) 

if  (beg_line  1-  ‘selection) 
mvpr  intw(  y__coord ,  0,  "%s",  line_ptr [ beg_line ] ) ; 
else 

process_message ( & value ) ; 

++y_coord; 

} 

move (23,  0); 
cl rtoeol ( ) ; 
touchwin( stdscr ) ; 
ref resh( ) ; 

endwin( trace_window) ; 

endwinj); 

exit( ) ; 

} 
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highlight^  code ) 
int  *code; 


wstandout( trace_window ) ; 

switch( *code ) 

{ 

case  1: 

wprintw( trace_window, "  PRESS  'q':  quit 

'c':  trace  display  'x':  execute  "); 

break; 
case  2: 

wprintw( trace_window, 

"  To  continue  press  spacebar 

break; 
case  3: 

mvwprintw( trace_window,  y_coord,  5,  "%s", 
line_ptr lbeg_line ] ) ; 

break; 
case  4: 

mvwprintw( trace_window,  0,  0, 

"Suspect  variable:  %s",  variable); 


wstandend( trace  window); 

} 
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